這是筆者第三次參加 iThome 鐵人賽。與前兩次最大的不同在，這次我是一開始還沒報名時，就把名字想好了。
細心的讀者們應該已經發現了，這系列文章，是致敬 2022 年 Netflix 的影集「毒梟聖徒」命名的（黃晸珉真心帥）。
還記得幾個月前，有一次下班前與同事聊天，從例外處理的流派講到開發流程的流派，最後再講到程式語言的流派，最後得出一個結論叫做：只要能解決問題，並且不造成更多後續的麻煩，那麼流派之爭其實是沒什麼意思的。離開前同事問我說那 Clean Code 呢？我說：「那不是流派，是信仰。」
結束之後，我在回家路上想了又想，回家後馬上查了一下何謂信仰。維基百科說：「信仰是對某事或某人的一種強烈的堅定不疑的信念，處於難以被客觀證據和理性分析而改變心理狀態。」
「難以被客觀證據改變呀！」為了這句，我想了許久…
確實，一開始接觸敏捷開發，是因為在工作當中遭遇到某些流程上的困難，覺得很頓、很卡，而過去學校教的內容卻從來不考慮這些事情。問職場上的老前輩，老前輩都說這些都是必經的過程，叫我自己想辦法解決，過了就過了。我總是覺得不對啊，我現在面前遇到的問題肯定不只有我一個人遇過，難道世界上都沒有任何人提出任何理論來解決這些流程上卡頓的問題嗎？於是，在朋友的介紹之下才第一次去上了泰迪軟體難得在台中開的的 Scrum 實作班，這才算是我第一次認真接觸到敏捷開發。
後來的故事，就如同前面的章節提到的，大家都看到了。在書本上學習的敏捷開發的流程與知識，在現實生活當中要套用的時候，幾乎沒有辦法馬上套用。應該說，後來才發現花時間想要怎麼跟別人解釋什麼叫敏捷，其實是沒有必要的，你應該要跟別人解釋的是「你想要用什麼方法來解決我們面前遇到的開發流程的問題」。甚至到最後你會發現，其實也根本就不需要解釋，面對問題的是你自己，你自己就動手去學習一些新的知識拿回來套用，並且解決你眼前的問題就好了。說到底，敏捷開發到底解決了什麼問題？還不就是與客戶互動、溝通、開發與測試的問題嗎？
如果這些問題都能得到解決，那是不是敏捷開發真的那麼重要嗎？好像也就沒那麼重要了。
既然不那麼重要，那為什麼筆者這些年來還是一直在做敏捷開發與自動化測試的相關研究呢？過去若有人真的問我這個問題，我想我應該是答不出來的。
這兩年筆者發現了一本書，作者的立論挺有趣的，書名叫「史上最強哲學入門：東方哲人」。書中介紹的幾位哲人們，都練就了一身必殺技。例如釋迦牟尼的必殺技為無我，孔子的必殺技為仁與禮，老子的必殺技叫無為等。這些哲學家來說，解釋世界的樣貌，並打造一個更好的世界同為目的，而只是各自練就了不同必殺技而已。
這麼說來，也許 Kent Beck 的必殺技可以叫 TDD、Martin Fowler 的必殺技也可以叫 Refactoring 囉？無論他們的必殺技為何，但我相信其最終目的應該是差不多的。
那是什麼？還不就是大家背得很熟的「藉著親自並協助他人進行軟體開發，致力於發掘更優良的軟體開發方法」嗎？
在過去的幾年當中，筆者投身的軟體環境中，技術當然富含挑戰，但都不是最大的問題，規格亦非。最大的問題，還是在於參與者們對於現在正在開發的產品創造了什麼價值並不了解。當我不知道我現在在實現的 Solution 解決了什麼問題的時候，我們經常在重複的用不同的 Solutions 解決同一個問題（ which 我還是不知道是什麼問題）。而在經過好一段時間的努力之後，我們終於從失敗當中逐漸摸索出客戶真的想要解決問題時，回頭一看，當初付出的那些努力根本大部分都是更早就可以避免的，只要我可以提早交付、提早驗證、提早摸索出用戶的 Context，那麼中間這些付出過的努力、那些無數個加班到深夜的夜晚通通都可以省掉，而創造的價值一樣多。何樂而不為？
然而，一套方法要能夠發揮效用，首先你得要去做。你不做，你怎麼知道對還是不對？你怎麼知道對你來說有沒有有效？但此時又產生一個矛盾了：「我要做了才能確定有效，那我做之前到底是靠著什麼來下定決心開始改變的呢？」過去的這幾個月，我時不時的都在想這個問題。
想到最後我想通了：就是「信仰」啊！
因為學習到了理論，拿著這套理論來對比自己眼前遇到的狀況，發現這兩個狀況是相符的，於是在沒有過去任何經驗的佐證底下，就埋頭下去嘗試著改變，就算路上遇到阻礙也只是試著改變做法，而不輕言放棄。說真的，要能做到像這樣子的事情，若不是靠著信仰的力量，那還能是什麼力量呢？老闆嗎？你做這些事情老闆又不會多給你錢，對吧？
話說回來，雖說一開始的確是靠著信仰的力量而前行的，但事實上，過了一段時間後就開始得到了一些回報。
舉例來說，當全世界都不做單元測試的時候，我來當這第一個人，得到的回報就是當全世界都在上線前趕著加班、趕著修 Bug、趕著等 QA 重複驗測的時候，我幾乎可以天天準時下班回家吃晚餐。
舉例來說，當全世界都等著企劃出一個完整的企劃書，得到企劃書之後花三個月完成一個專案再等一個月的 QA，最後上線發現這整個企劃書根本就有一個假設性的錯誤，這時我的產品已經迭代三輪到四輪，並且已經從真實用戶的回饋以及表現當中得到改善的數據，並且也改善過三輪或四輪了。我不敢說這些產品是完美的，但是至少我能夠得到真實的用戶回饋，避免真實的錯誤重複的發生，而同時把浪費壓到最低。
雖然一開始是靠著信仰的力量前行沒錯，但其實到後來都已經脫離信仰的範疇了，而是靠著實驗的力量，也就是「科學」在支撐著這個信念繼續往下走。
這也就是為什麼過了這麼多年我依然在這邊做著敏捷開發與自動化測試的研究與推廣。原因無他，就是因為我親眼見證、親身體驗了這樣子的工作方式帶來的好處與創造的價值，這不再是信仰，這已經是科學了.
在本系列文章連載到一半的時候，筆者曾經在網路上看到針對這些文章的一些批評指教，其中包含「邪教」這個強烈的字眼，如下圖：
其實這一位推文者的心情，我完全可以理解。過去的這四五年，敏捷開發這個名詞曾經一度在軟體開發界佔據很重要的熱搜位置，大家都在學，大家都想透過敏捷開發來改善自己的開發環境。
然而，師父引進門，修行在個人。十個人讀同一本書，可能會產生 12 種見解，因為有些人可能一個人就有兩三種見解。有些不同的見解倒無妨，但有些人在把這套敏捷開發的工作方式套回去自己公司的時候，做了一些因地制宜或因人制宜的改變。這些改變有些無傷大雅，但有些從根本上就悖離了敏捷開發最根本的精神。
舉例來說，前文中就有提過，某些團隊是有了一個很完整的規格書，之後在三個月內用 Scrum 的流程，每兩週每兩週的去把這規格書的內容給刻出來，中間不管發生什麼事情，規格書的內容都不可以改，而且所有事情都全部做完後，還得再經過一個月驗測才能上線。各位請試想，這樣子的工作方式，真的有敏捷到嗎？如果你也認為沒有敏捷到，那這群人跑到外面去跟人家說我在敏捷並且敏捷爛透了，你就可以想像敏捷為他們的誤解背了多少黑鍋。
所以，在這個世界上有太多太多一聽到敏捷寒毛就豎起來，立刻進入防衛模式的人，這是完全可以想見的。
在 Christopher Alexander 的理念中，分析 Context 是非常重要的事情。Alexander 提出了幾百個建築的模式，構成模式語言，但你從來不會在一棟建築物當中同時看到所有的建築模式，如果有的話會非常的荒謬。為什麼？因為被一棟建築物所服務的人，他們想達成的目的是有限的，因此 Alexander 認為模式只要能解決使用這座建築物的人的問題，那就是好的設計，跟套了幾個模式沒有關係。
軟體也是啊！當你今天引入一個新的工作模式，你得先看看這一個工作模式當初被發明的時候是不是想要解決你當下面對的問題呀！
假設你今天經常接收到的抱怨是「客戶都不說清楚他想要什麼，害我一直要重複改」，這時你可能有兩個方向來緩解你的問題：
第一個方向：你可以在過程中不斷透過測試的保護來重構，讓你的程式始終維持在一個彈性不錯的程度，如此一來客戶要怎麼改你都不會太痛苦。
第二個方向：你在開始之前就先用類似 Prototype 的方式，盡量在「問題面」上盡早與客戶達成共識，知道客戶正在面臨什麼痛苦，知道痛苦之後再幫他提 Solution。
這兩種方法都能夠舒緩你原本的痛苦，然而如果你都不這麼做，你出去參加一個研討會回來之後告訴老闆說：「啊，我知道了！我們要用微服務來解決我們跟客戶溝通的問題！」
同學，你拿什麼解藥來解什麼毒啊？
再退一步來說，如果你面臨到的問題根本就不是敏捷開發一開始想解決的問題，那你拿來套用之後當然會掛啊！譬如說你的 RD 根本就對於什麼叫做單元測試不了解也不想了解也不想做，那你跑 Scrum 會掛的！為什麼？因為你每週做五個功能、每週做五個功能，RD 做得很開心，QA 卻測得很痛苦，因為他第一週要測五個功能、第二週要測十個功能、第三週要測 15 個功能… 以此類推啊！
如果你的問題只是 QA 測試太慢，你不想等太久，那你不應該一開始就走 Scrum，你應該一開始先做單元測試。為什麼？因為當功能面的東西 RD 都測完了，QA 不就可以省下時間去測那些只有人類測得到的東西了嗎？譬如說易用性、畫面跳轉流程合理性等，對吧？
這時，有人可能會說：「我只是個打工仔，你叫我解決公司開發流程上的問題要做什麼？我又沒有領那個錢，就算解決了也沒有人誇獎我。」很合理，對吧？
如果你要這麼想的話，的確是的。你只是個打工仔，當你今天因為公司的組織分組不當，加上分工不清，而造成了之前提到的本地最大化、專案空轉、人力浪費、公司虧錢…等，這些都沒有你的事，因為而且你也不用扛任何責任，因為你只是個打工仔。
問題是，你現在不就是已經面臨到一個你沒辦法好好工作，或是一上班就會生氣就會抱怨的情況了嗎？如果今天公司真的虧錢，那麼你真的能夠一如往常地開開心心踏踏實實地打好你的工嗎？難道你不會是裁員的第一個下手對象嗎？
不論如何，我都祝福你。
說到底，開發是不是一定要敏捷才是對的？當然不是！
「正義：一場思辨之旅」這本書裡面，作者告訴我們的是，在這個社會上，所謂的正義是什麼，這件事不同的人來看會有不同的想法。想法不同沒關係，誰對誰錯不是重點，重點是思辨的過程。
舉例來說，「籃球之神」Michael Jordan 富可敵國這件事眾所皆知。針對Michael Jordan 該不該領這麼高的薪水、該不該擁有這麼高的收入，或是他應該要繳多少的稅，這件事情就有非常多種思辨方法。
有人認為 Michael Jordan 的成功不是靠他個人的努力就能夠完成的，例如他過人的天賦如果打了折扣，或是他打籃球的年代如果社會氛圍不同，他根本就沒有辦法擁有現在的表現，因此他的財富應該（至少有部份）屬於公共社會。
有人認為 Michael Jordan 如果只有天賦而不努力，他也完全沒有辦法達到現在的身分地位。在NBA的歷史中有太多天份比他好，但成就遠不如他的人，於是他的財富不只不用跟人家分享，甚至連繳稅都是多餘的，因為他的每一分錢都是靠自己努力得來的。
作者桑德爾認為，這些對於正義的思辨的辯論沒有對錯之分，值得鼓勵的是辯論的過程，因為為了辯論，你會收集很多資料、會做很多的驗證、會進行一個人類很重要的行為，叫做「思考」。因為有了思考，人類才有存在的價值；因為有了思考，人類才會進步到現在這個樣子。
我十分認同作者的論調。身為軟體開發工作者，我其實也沒有這麼偉大到想要去討論 Michael Jordan 的財富到底要分多少給社會大眾。但我想說的是，假設你今天讀了我的文章、聽了我的演講之後，回去想都不想的把我的工作的模式，或文章中寫的內容直接就套在你的團隊裡面，那你其實也就缺少了思考：「誰說照我的做法才叫敏捷？誰說敏捷就一定好？」
真實的去感受你現在面臨的問題，找出問題的根源。找出根源後，試著用盡量不增加副作用的方式去解決它。維持一段時間，繼續觀察，當新問題再度出現時，用一樣的思考方式去想新 Solution 以解決新的問題，這樣子不斷地循環下去，你的工作環境要有多痛苦，我想也很難了。
反過來，如果你只是不斷重複抱怨說：「我只是打工的我不是老闆這些不是我的問題老闆爛透了客戶笨死了同事壞死了」，那問題永遠是問題，而你業已不在，因為你已經停止思考了。
如果你真的什麼都不想想、什麼都不想改、什麼都不想多做，那沒關係，不然你就不要抱怨，總做得到了吧？
最後，就當我們真的是邪教吧！邪教又怎樣？我自己實驗過無數次，得到一些經驗（好壞都有），然後拿我自身的經驗，佐以理論與分析來分享給各位讀者，如果各位也覺得有理、可能有搞頭，那就歡迎入教，一起來改善我們的開發環境！
如果覺得沒搞頭，那也無妨。只是我還是勸你停止抱怨，真正「 打開眼睛看、拿出頭腦想、捲起袖子動手做」，才有機會用你自己的方法，真正改善你的工作環境。
最後，邪教又怎樣？你有得邪嗎？
謎之聲：「我思，故我在。」
謝謝大師，有機會拜讀這系列的文章真的是受益匪淺，很多觀念都值得大家省思一下，而且都很有深度，可能我資質沒有很好，覺得需要多再看幾次，反芻幾次才有機會內化成為自己的東西。
iThome鐵人賽
看影片追技術